January 92 - Object Master 1.0ß4
Object Master 1.0B4
Jeffrey J. Barbose
Because of the near-ubiquity of structured programming, most tools (and languages)
have been designed to aid in structured software development. Witness MPW and the
THINK products, which provide access to such traditional mainstays as source-level
debugging, ordinary (linear) text editing tools, and the familiar edit-compile-run
development cycle. The most popular object-oriented programming languages (C++,
Object Pascal, Modula2-P1) are merely structured languages with extensions to
support the enforcement of object concepts; they may thus be called "hybrid
languages.
Early object-oriented languages, such as Smalltalk, are "pure" object languages. They
espouse the "everything is an object" concept-a radical departure from traditional
systems. Unfettered by the need to appear similar to existing structured development
tools, Smalltalk inventors created an entire development and run-time environment
based on the concept of a virtual machine: Smalltalk is designed so that every
component of the system that is accessible to the user can be presented in a meaningful
way for observation and manipulation." In other words, the complexities involved in
larger-scale object-oriented software development were addressed right from the
beginning.
All along, MacApp programmers have been creating their classes and interactions
without a "meaningful way for observation and manipulation" of MacApp's complexity.
With one or two exceptions, Object Master from ACIUS provides a complete
environment for object-oriented software development.
Divide et impera
The purpose of software design, analysis and construction is complexity management.
Decomposition, abstraction and hierarchical organization each have roles in the design
of non-trivial applications.
The goal of improving design techniques is to find the best symbolic mapping of the
problem domain to the software solution domain. Development environments should
also provide as close to a one-to-one mapping of programming
paradigm-to-program-development as possible; namely, the class (or, more
generally, the module) should represent the fundamental unit for editing source code.
Shifting paradigms
The benefits of a gestalten object development environment are not immediately
obvious. In fact, traditional environments are often adequate (though not optimal) to
the task of object programming.
MacBrowse and SourceBug are two notable additions to the MPW development system
that are designed for object programming. The need for breadth- and depth-browsing
of classes-especially classes within a well-defined framework-quickly becomes
obvious when trying to familiarize yourself with MacApp.
Browsing, as a general tool, organizes hierarchical (and, to a lesser extent, reticular)
systems in a straightforward, meaningful way. The browser nature of SourceBug is its
advantage over SADE with respect to MacApp programming.
The editing environment of MPW and the THINK products require you to implement
object-oriented constructs within the world of structured programming-manual
construction and maintenance of separate interface and implementation files, #include
and other compiler directive management, etc.
Described in its manual as an editing tool, Object Master is much more. It provides,
through internal facilities and through AppleEvent magic, a virtual environment
expressly tailored to the needs of developers of object-oriented applications-with or
without MacApp. Browsing with full editing allows object-oriented development to
proceed apace, and eliminates the need to fit your object-oriented code into a
structured source format.
elemental overview
Object Master is a large, complex program. Large in the sense that there are many
visual components; complex in the sense that it incorporates and automates nearly
every activity involved in object-oriented development.
Even to review such a product requires a bit of complexity management, so I'll first
describe it, component by component. Again, it helps to think of Object Master as more
of an integrated environment than a Macintosh application.
_ValidateConfiguration(gConfiguration);
Object Master requires at least System 6, but to take full advantage of its features (in
particular, Apple Events), System 7 is recommended. Most of this review was written
while working with 1.0B2, but 1.0B4 arrived near the tail end of the process.
I ran Object Master on a IIci with 32mb RAM, System 7, and 32-bit addressing on.
1.0B4 requests a 1480K partition, but may require an even larger partition if the
MacApp CPlusIncludes and Libraries are to be included in a given project.
Since Object Master requires a separate, external compiler, you must also have
enough RAM to run MPW/ToolServer (MPW 3.3 and ToolServer 1.0 or better are
required) or a THINK system. Object Master can also control (to varying degrees)
other development tools, including Jasik Designs' The Debugger/Integrated Build
System, ResEdit, ViewEdit and IcePick. Decide which of these tools you'd like to have
running concurrently to determine how much RAM you will require. For example, to
run Object Master, MPW/ToolServer, and C++, you'll need 8mb at the very least.
Project-centered design Object Master organizes source files, classes, methods,
fields, resources, and documentation-in other words, all application
components-inside a project. An Object Master project is similar to a THINK Pascal or
Think C project, or an MPW/ToolServer Projector database.
Unlike other source code systems, the Object Master project takes an active role. It
acts like a control center for software development, orchestrating all development
activities to some degree. For instance, if you're using MPW/ToolServer, you can
specify an MPW Projector database and do simple CheckIns and CheckOuts, all from
within Object Master, via Apple Events. Object Master respects Projector status on all
files. When source files are added to a project, or existing source files have changed,
Object Master parses those files and adds class, method, field, file and segment
information to a project dictionary. You can use this dictionary to do project-wide
searches. Object Master uses this dictionary to generate its views.
Object Master's application menu bar
Every Macintosh application makes use of the Macintosh menu bar to control
application functionality. Object Master does as well, but it provides only commands
that have effects outside the scope of any one project. File-, class-, method- and
field-specific commands are handled from within the Object Master windows and will
be described later. The menus and their items are well organized and are aptly named,
resulting in straightforward, intuitive use.Briefly, Object Master's menu bar is as
follows:
File Fairly standard Macintosh file menu. The New and Open items refer to
source code files, not Object Master projects.
Edit Standard Macintosh Edit menu. Also provides menu items for code
alignment and duplication.
Settings Allows for preferences with respect to the appearance of
language-specific constructs within editing views. Project preferences
are also available (see Figure 1).
Project Contains all commands for opening, closing, saving whole projects,
adding source files and 411 (MPW help format) files, and source code
parsing.
Build Automated, AppleEvent- or QuicKey-orchestrated application building
functions. Provides specific access to MPW/ToolServer, THINK
compilers, and Jasik's IBS.
Goodies Mainly provides access to documentation facilities. Also allows for
project-wide text searching and project meta-functions for writing
Make files, Fields information, and for constructing 411
documentation.
Windows Commands for creating new instances of each of Object Master's
project-related windows, and for organizing existing windows.
Bar Hopping
To call the views within Object Master "windows" doesn't quite do them justice. Each
window contains its own menu bar, and acts more like a mini-application within the
Object Master virtual environment. A window's menu bar behaves exactly as a
standard Macintosh menu. It was surprisingly easy to get used to having additional
menu bars within the windows. Object Master's main windows are described below.
Project Window
Figure 2 is a Project Window. Its primary purpose is the organization and
presentation of the files (source, resource, help and other files) that are included in
an Object Master project. The menu bar contains the following:
Files Allows opening and printing any file contained in the project; specifying
and selecting an MPW Projector Database; and checking files in and out
of that database.
Columns Control visibility of various file attributes, such as Unit name,
Projector status, or modification date.
Sort Sort the list by any of the file attributes, in ascending or descending
order.
Color Set any file to any color.
Browser Window
Figure 3 is a Browser Window. This is where nearly all day-to-day interaction with
Object Master takes place.
Those of you familiar with the Smalltalk/V or Objectworks Smalltalk-80
environments will feel right at home within the Browser. In standard fashion, the
browser is split up into four panes: Class List, Method List, Field List, and Edit view.
This window is responsible for hiding most of the standard file-based housekeeping.
With it you can create and modify classes, and add and remove methods and fields.
Modules (units) and structs (records) are added as pseudo classes, and denoted in the
Class List with a prepended "•" for modules, "••" for structs. Any functions or
procedures that are outside the scope of any class become pseudo-methods of that
pseudo-class.
To create a subclass of another class, select the class that is to serve as the new class'
superclass. When creating new classes, you are presented with the New Class Dialog
(Figure 4). Object Master will create new interface and implementation files to
contain the nascent class. The Location buttons are used to specify where the new files
will be saved.
It would be convenient here to be able to specify an existing file, since it is often
preferable to have a number of classes all within one file. As Booch suggests, the
module (unit)-not the class-is the fundamental construct in an object-oriented
system. In this way, any number of functionally interdependent classes can be
gathered, and so visibility can be determined and restricted as a group.
It is possible, at this point, to specify (by double-clicking) any existing method as
being one that will be overridden in this new derived class. Conveniently, this list
contains not only the methods of the immediately ancestral class, but the methods of all
the classes from which it is inheriting.
The only significant instance where Object Master fails to present a complete object
environment is in the creation of the interface and implementation files. There is
currently no means of specifying #include files, other than by opening the files and
manually adding the necessary compiler directives to both files. It would be nice if the